ZAP Scanning Report
| Risk Level | Number of Alerts |
|---|---|
|
High
|
5
|
|
Medium
|
5
|
|
Low
|
3
|
|
Informational
|
6
|
|
False Positives:
|
0
|
| Name | Risk Level | Number of Instances |
|---|---|---|
| Cross Site Scripting (Reflected) | High | 7 |
| Path Traversal | High | 2 |
| Remote OS Command Injection | High | 3 |
| SQL Injection | High | 2 |
| SQL Injection - MySQL | High | 2 |
| Absence of Anti-CSRF Tokens | Medium | 33 |
| Application Error Disclosure | Medium | 9 |
| Content Security Policy (CSP) Header Not Set | Medium | 79 |
| Directory Browsing | Medium | 16 |
| Missing Anti-clickjacking Header | Medium | 66 |
| Strict-Transport-Security Header Not Set | Low | 93 |
| Timestamp Disclosure - Unix | Low | 5 |
| X-Content-Type-Options Header Missing | Low | 71 |
| Authentication Request Identified | Informational | 4 |
| Information Disclosure - Sensitive Information in URL | Informational | 12 |
| Information Disclosure - Suspicious Comments | Informational | 2 |
| Re-examine Cache-control Directives | Informational | 72 |
| User Agent Fuzzer | Informational | 84 |
| User Controllable HTML Element Attribute (Potential XSS) | Informational | 26 |
| HTTP Response Code | Number of Responses |
|---|---|
| 200 OK |
2
|
| Parameter Name | Type | Flags | Times Used | # Values |
|---|
| HTTP Response Code | Number of Responses |
|---|---|
| 200 OK |
6
|
| Parameter Name | Type | Flags | Times Used | # Values |
|---|
| HTTP Response Code | Number of Responses |
|---|---|
| 200 OK |
6
|
| Parameter Name | Type | Flags | Times Used | # Values |
|---|
| HTTP Response Code | Number of Responses |
|---|---|
| 200 OK |
1
|
| Parameter Name | Type | Flags | Times Used | # Values |
|---|
| HTTP Response Code | Number of Responses |
|---|---|
| 404 Not Found |
4
|
| Parameter Name | Type | Flags | Times Used | # Values |
|---|
| HTTP Response Code | Number of Responses |
|---|---|
| 403 Forbidden |
15
|
| 404 Not Found |
941
|
| 200 OK |
7079
|
| 421 Misdirected Request |
12
|
| 301 Moved Permanently |
346
|
| Parameter Name | Type | Flags | Times Used | # Values |
|---|
|
High |
Cross Site Scripting (Reflected) |
|---|---|
| Description |
Cross-site Scripting (XSS) is an attack technique that involves echoing attacker-supplied code into a user's browser instance. A browser instance can be a standard web browser client, or a browser object embedded in a software product such as the browser within WinAmp, an RSS reader, or an email client. The code itself is usually written in HTML/JavaScript, but may also extend to VBScript, ActiveX, Java, Flash, or any other browser-supported technology.
When an attacker gets a user's browser to execute his/her code, the code will run within the security context (or zone) of the hosting web site. With this level of privilege, the code has the ability to read, modify and transmit any sensitive data accessible by the browser. A Cross-site Scripted user could have his/her account hijacked (cookie theft), their browser redirected to another location, or possibly shown fraudulent content delivered by the web site they are visiting. Cross-site Scripting attacks essentially compromise the trust relationship between a user and the web site. Applications utilizing browser object instances which load content from the file system may execute code under the local machine zone allowing for system compromise.
There are three types of Cross-site Scripting attacks: non-persistent, persistent and DOM-based.
Non-persistent attacks and DOM-based attacks require a user to either visit a specially crafted link laced with malicious code, or visit a malicious web page containing a web form, which when posted to the vulnerable site, will mount the attack. Using a malicious form will oftentimes take place when the vulnerable resource only accepts HTTP POST requests. In such a case, the form can be submitted automatically, without the victim's knowledge (e.g. by using JavaScript). Upon clicking on the malicious link or submitting the malicious form, the XSS payload will get echoed back and will get interpreted by the user's browser and execute. Another technique to send almost arbitrary requests (GET and POST) is by using an embedded client, such as Adobe Flash.
Persistent attacks occur when the malicious code is submitted to a web site where it's stored for a period of time. Examples of an attacker's favorite targets often include message board posts, web mail messages, and web chat software. The unsuspecting user is not required to interact with any additional site/link (e.g. an attacker site or a malicious link sent via email), just simply view the web page containing the code.
|
| URL | https://vulnweb.rootbrain.com/FileInclusion/pages/lvl1.php?file=%3C%2Fh5%3E%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E%3Ch5%3E |
| Method | GET |
| Parameter | file |
| Attack | </h5><scrIpt>alert(1);</scRipt><h5> |
| Evidence | </h5><scrIpt>alert(1);</scRipt><h5> |
| Request Header - size: 817 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 851 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileInclusion/pages/lvl2.php?file=%3C%2Fh5%3E%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E%3Ch5%3E |
| Method | GET |
| Parameter | file |
| Attack | </h5><scrIpt>alert(1);</scRipt><h5> |
| Evidence | </h5><scrIpt>alert(1);</scRipt><h5> |
| Request Header - size: 817 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 848 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level1.php?username=%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E&submit=Submit |
| Method | GET |
| Parameter | username |
| Attack | <scrIpt>alert(1);</scRipt> |
| Evidence | <scrIpt>alert(1);</scRipt> |
| Request Header - size: 828 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 661 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level2.php?username=%3CscrIpt%3Ealert%281%29%3B%3C%2FscRipt%3E&submit=Submit |
| Method | GET |
| Parameter | username |
| Attack | <scrIpt>alert(1);</scRipt> |
| Evidence | <scrIpt>alert(1);</scRipt> |
| Request Header - size: 828 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 663 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level4.php?username=%3Cimg+src%3Dx+onerror%3Dprompt%28%29%3E&submit=Submit |
| Method | GET |
| Parameter | username |
| Attack | <img src=x onerror=prompt()> |
| Evidence | <img src=x onerror=prompt()> |
| Request Header - size: 826 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 587 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileUpload/fileupload1.php |
| Method | POST |
| Parameter | file |
| Attack | <img src=x onerror=prompt()> |
| Evidence | <img src=x onerror=prompt()> |
| Request Header - size: 917 bytes. | |
| Request Body - size: 313 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 704 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql3.php |
| Method | POST |
| Parameter | number |
| Attack | '"<scrIpt>alert(1);</scRipt> |
| Evidence | '"<scrIpt>alert(1);</scRipt> |
| Request Header - size: 853 bytes. | |
| Request Body - size: 69 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 830 bytes. | |
| Instances | 7 |
| Solution |
Phase: Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
Examples of libraries and frameworks that make it easier to generate properly encoded output include Microsoft's Anti-XSS library, the OWASP ESAPI Encoding module, and Apache Wicket.
Phases: Implementation; Architecture and Design
Understand the context in which your data will be used and the encoding that will be expected. This is especially important when transmitting data between different components, or when generating outputs that can contain multiple encodings at the same time, such as web pages or multi-part mail messages. Study all expected communication protocols and data representations to determine the required encoding strategies.
For any data that will be output to another web page, especially any data that was received from external inputs, use the appropriate encoding on all non-alphanumeric characters.
Consult the XSS Prevention Cheat Sheet for more details on the types of encoding and escaping that are needed.
Phase: Architecture and Design
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
Phase: Implementation
For every web page that is generated, use and specify a character encoding such as ISO-8859-1 or UTF-8. When an encoding is not specified, the web browser may choose a different encoding by guessing which encoding is actually being used by the web page. This can cause the web browser to treat certain sequences as special, opening up the client to subtle XSS attacks. See CWE-116 for more mitigations related to encoding/escaping.
To help mitigate XSS attacks against the user's session cookie, set the session cookie to be HttpOnly. In browsers that support the HttpOnly feature (such as more recent versions of Internet Explorer and Firefox), this attribute can prevent the user's session cookie from being accessible to malicious client-side scripts that use document.cookie. This is not a complete solution, since HttpOnly is not supported by all browsers. More importantly, XMLHTTPRequest and other powerful browser technologies provide read access to HTTP headers, including the Set-Cookie header in which the HttpOnly flag is set.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
Ensure that you perform input validation at well-defined interfaces within the application. This will help protect the application even if a component is reused or moved elsewhere.
|
| Reference |
http://projects.webappsec.org/Cross-Site-Scripting
http://cwe.mitre.org/data/definitions/79.html |
| Tags |
OWASP_2021_A03
WSTG-v42-INPV-01 OWASP_2017_A07 |
| CWE Id | 79 |
| WASC Id | 8 |
| Plugin Id | 40012 |
|
High |
Path Traversal |
|---|---|
| Description |
The Path Traversal attack technique allows an attacker access to files, directories, and commands that potentially reside outside the web document root directory. An attacker may manipulate a URL in such a way that the web site will execute or reveal the contents of arbitrary files anywhere on the web server. Any device that exposes an HTTP-based interface is potentially vulnerable to Path Traversal.
Most web sites restrict user access to a specific portion of the file-system, typically called the "web document root" or "CGI root" directory. These directories contain the files intended for user access and the executable necessary to drive web application functionality. To access files or execute commands anywhere on the file-system, Path Traversal attacks will utilize the ability of special-characters sequences.
The most basic Path Traversal attack uses the "../" special-character sequence to alter the resource location requested in the URL. Although most popular web servers will prevent this technique from escaping the web document root, alternate encodings of the "../" sequence may help bypass the security filters. These method variations include valid and invalid Unicode-encoding ("..%u2216" or "..%c0%af") of the forward slash character, backslash characters ("..\") on Windows-based servers, URL encoded characters "%2e%2e%2f"), and double URL encoding ("..%255c") of the backslash character.
Even if the web server properly restricts Path Traversal attempts in the URL path, a web application itself may still be vulnerable due to improper handling of user-supplied input. This is a common problem of web applications that use template mechanisms or load static text from files. In variations of the attack, the original URL parameter value is substituted with the file name of one of the web application's dynamic scripts. Consequently, the results can reveal source code because the file is interpreted as text instead of an executable script. These techniques often employ additional special characters such as the dot (".") to reveal the listing of the current working directory, or "%00" NULL characters in order to bypass rudimentary file extension checks.
|
| URL | https://vulnweb.rootbrain.com/FileInclusion/pages/lvl1.php?file=%2Fetc%2Fpasswd |
| Method | GET |
| Parameter | file |
| Attack | /etc/passwd |
| Evidence | root:x:0:0 |
| Request Header - size: 771 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 3,110 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileInclusion/pages/lvl2.php?file=%2Fetc%2Fpasswd |
| Method | GET |
| Parameter | file |
| Attack | /etc/passwd |
| Evidence | root:x:0:0 |
| Request Header - size: 771 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 3,107 bytes. | |
| Instances | 2 |
| Solution |
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
For filenames, use stringent allow lists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses, and exclude directory separators such as "/". Use an allow list of allowable file extensions.
Warning: if you attempt to cleanse your data, then do so that the end result is not in the form that can be dangerous. A sanitizing mechanism can remove characters such as '.' and ';' which may be required for some exploits. An attacker can try to fool the sanitizing mechanism into "cleaning" data into a dangerous form. Suppose the attacker injects a '.' inside a filename (e.g. "sensi.tiveFile") and the sanitizing mechanism removes the character resulting in the valid filename, "sensitiveFile". If the input data are now assumed to be safe, then the file may be compromised.
Inputs should be decoded and canonicalized to the application's current internal representation before being validated. Make sure that your application does not decode the same input twice. Such errors could be used to bypass allow list schemes by introducing dangerous inputs after they have been checked.
Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links.
Run your code using the lowest privileges that are required to accomplish the necessary tasks. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
|
| Reference |
http://projects.webappsec.org/Path-Traversal
http://cwe.mitre.org/data/definitions/22.html |
| Tags |
OWASP_2021_A01
WSTG-v42-ATHZ-01 OWASP_2017_A05 |
| CWE Id | 22 |
| WASC Id | 33 |
| Plugin Id | 6 |
|
High |
Remote OS Command Injection |
|---|---|
| Description |
Attack technique used for unauthorized execution of operating system commands. This attack is possible when an application accepts untrusted input to build operating system commands in an insecure manner involving improper data sanitization, and/or improper calling of external programs.
|
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-1.php?username=cat+%2Fetc%2Fpasswd&password= |
| Method | GET |
| Parameter | username |
| Attack | cat /etc/passwd |
| Evidence | root:x:0:0 |
| Request Header - size: 801 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 3,370 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-2.php?typeBox=UImXUGAB%26sleep+5.0%26 |
| Method | GET |
| Parameter | typeBox |
| Attack | UImXUGAB&sleep 15& |
| Evidence | |
| Request Header - size: 794 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 992 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-4.php?typeBox=cat+%2Fetc%2Fpasswd |
| Method | GET |
| Parameter | typeBox |
| Attack | cat /etc/passwd |
| Evidence | root:x:0:0 |
| Request Header - size: 790 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 3,193 bytes. | |
| Instances | 3 |
| Solution |
If at all possible, use library calls rather than external processes to recreate the desired functionality.
Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by your software.
OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows you to specify restrictions on file operations.
This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise.
For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the command locally in the session's state instead of sending it out to the client in a hidden form field.
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, consider using the ESAPI Encoding control or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
If you need to use dynamically-generated query strings or commands in spite of the risk, properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allow list (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection.
If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line.
If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.
Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use an allow list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. Do not rely exclusively on looking for malicious or malformed inputs (i.e., do not rely on a deny list). However, deny lists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if you are expecting colors such as "red" or "blue."
When constructing OS command strings, use stringent allow lists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.
Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components.
Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.
|
| Reference |
http://cwe.mitre.org/data/definitions/78.html
https://owasp.org/www-community/attacks/Command_Injection |
| Tags |
OWASP_2021_A03
OWASP_2017_A01 WSTG-v42-INPV-12 |
| CWE Id | 78 |
| WASC Id | 31 |
| Plugin Id | 90020 |
|
High |
SQL Injection |
|---|---|
| Description |
SQL injection may be possible.
|
| URL | https://vulnweb.rootbrain.com/SQL/sql1.php |
| Method | POST |
| Parameter | firstname |
| Attack | hKsCQUIV' OR '1'='1' -- |
| Evidence | |
| Request Header - size: 853 bytes. | |
| Request Body - size: 61 bytes. | |
| Response Header - size: 211 bytes. | |
| Response Body - size: 643 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql3.php |
| Method | POST |
| Parameter | number |
| Attack | dQAWFILK' OR '1'='1' -- |
| Evidence | |
| Request Header - size: 853 bytes. | |
| Request Body - size: 58 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 745 bytes. | |
| Instances | 2 |
| Solution |
Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the principle of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.
|
| Reference | https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html |
| Tags |
OWASP_2021_A03
WSTG-v42-INPV-05 OWASP_2017_A01 |
| CWE Id | 89 |
| WASC Id | 19 |
| Plugin Id | 40018 |
|
High |
SQL Injection - MySQL |
|---|---|
| Description |
SQL injection may be possible.
|
| URL | https://vulnweb.rootbrain.com/SQL/sql1.php |
| Method | POST |
| Parameter | firstname |
| Attack | hKsCQUIV' / sleep(15) / ' |
| Evidence | |
| Request Header - size: 853 bytes. | |
| Request Body - size: 61 bytes. | |
| Response Header - size: 14 bytes. | |
| Response Body - size: 0 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql3.php |
| Method | POST |
| Parameter | number |
| Attack | dQAWFILK' / sleep(15) / ' |
| Evidence | |
| Request Header - size: 853 bytes. | |
| Request Body - size: 58 bytes. | |
| Response Header - size: 14 bytes. | |
| Response Body - size: 0 bytes. | |
| Instances | 2 |
| Solution |
Do not trust client side input, even if there is client side validation in place.
In general, type check all data on the server side.
If the application uses JDBC, use PreparedStatement or CallableStatement, with parameters passed by '?'
If the application uses ASP, use ADO Command Objects with strong type checking and parameterized queries.
If database Stored Procedures can be used, use them.
Do *not* concatenate strings into queries in the stored procedure, or use 'exec', 'exec immediate', or equivalent functionality!
Do not create dynamic SQL queries using simple string concatenation.
Escape all data received from the client.
Apply an 'allow list' of allowed characters, or a 'deny list' of disallowed characters in user input.
Apply the principle of least privilege by using the least privileged database user possible.
In particular, avoid using the 'sa' or 'db-owner' database users. This does not eliminate SQL injection, but minimizes its impact.
Grant the minimum database access that is necessary for the application.
|
| Reference | https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html |
| Tags |
OWASP_2021_A03
WSTG-v42-INPV-05 OWASP_2017_A01 |
| CWE Id | 89 |
| WASC Id | 19 |
| Plugin Id | 40019 |
|
Medium |
Absence of Anti-CSRF Tokens |
|---|---|
| Description |
No Anti-CSRF tokens were found in a HTML submission form.
A cross-site request forgery is an attack that involves forcing a victim to send an HTTP request to a target destination without their knowledge or intent in order to perform an action as the victim. The underlying cause is application functionality using predictable URL/form actions in a repeatable way. The nature of the attack is that CSRF exploits the trust that a web site has for a user. By contrast, cross-site scripting (XSS) exploits the trust that a user has for a web site. Like XSS, CSRF attacks are not necessarily cross-site, but they can be. Cross-site request forgery is also known as CSRF, XSRF, one-click attack, session riding, confused deputy, and sea surf.
CSRF attacks are effective in a number of situations, including:
* The victim has an active session on the target site.
* The victim is authenticated via HTTP auth on the target site.
* The victim is on the same local network as the target site.
CSRF has primarily been used to perform an action against a target site using the victim's privileges, but recent techniques have been discovered to disclose information by gaining access to the response. The risk of information disclosure is dramatically increased when the target site is vulnerable to XSS, because XSS can be used as a platform for CSRF, allowing the attack to operate within the bounds of the same-origin policy.
|
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-1.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-1.php" method="$_GET"> |
| Request Header - size: 761 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 1,087 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-1.php?password=ZAP&username=Admin |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-1.php" method="$_GET"> |
| Request Header - size: 411 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 157 bytes. | |
| Response Body - size: 1,087 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-1.php?username=Admin&password=adnib |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-1.php" method="$_GET"> |
| Request Header - size: 792 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 1,087 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-1.php?username=AdminxIZSCfSp&password= |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-1.php" method="$_GET"> |
| Request Header - size: 795 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 213 bytes. | |
| Response Body - size: 1,087 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-2.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-2.php" method="$_GET"> |
| Request Header - size: 761 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 992 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-2.php?typeBox=UImXUGAB |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-2.php" method="$_GET"> |
| Request Header - size: 779 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 992 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-3.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-3.php" method="$_GET"> |
| Request Header - size: 761 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 942 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-4.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-4.php" method="$_GET"> |
| Request Header - size: 761 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 910 bytes. | |
| URL | https://vulnweb.rootbrain.com/CommandExecution/CommandExec-4.php?typeBox=OKenSHYM |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form align="center" action="CommandExec-4.php" method="$_GET"> |
| Request Header - size: 779 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 910 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileUpload/fileupload1.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" enctype="multipart/form-data"> |
| Request Header - size: 743 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 653 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileUpload/fileupload2.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" enctype="multipart/form-data"> |
| Request Header - size: 743 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 656 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileUpload/fileupload3.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" enctype="multipart/form-data"> |
| Request Header - size: 743 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 655 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql1.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 726 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 634 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql2.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 726 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 650 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql3.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 726 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 737 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql4.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 726 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 872 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql5.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 726 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 758 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql6.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="get" > |
| Request Header - size: 726 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 684 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level1.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 732 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 622 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level1.php?username=EcTnsfli&submit=Submit |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 794 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 643 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level1.php?username=xvOiIwTz&submit=Submit |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 762 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 643 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level2.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 732 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 624 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level2.php?username=oDqaoRkJ&submit=Submit |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 794 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 645 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level2.php?username=RWnGdhJt&submit=Submit |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 762 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 645 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level3.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 732 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 619 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level4.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 732 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 559 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level4.php?username=FhDDmyON&submit=Submit |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 762 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 567 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level4.php?username=OYRJJkKD&submit=Submit |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="" name="form"> |
| Request Header - size: 794 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 567 bytes. | |
| URL | https://vulnweb.rootbrain.com/XSS/XSS_level5.php |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | <form method="GET" action="/vulnweb/XSS/XSS_level5.php" name="form"> |
| Request Header - size: 732 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 655 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileUpload/fileupload1.php |
| Method | POST |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" enctype="multipart/form-data"> |
| Request Header - size: 917 bytes. | |
| Request Body - size: 287 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 676 bytes. | |
| URL | https://vulnweb.rootbrain.com/FileUpload/fileupload3.php |
| Method | POST |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" enctype="multipart/form-data"> |
| Request Header - size: 917 bytes. | |
| Request Body - size: 287 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 660 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql1.php |
| Method | POST |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 853 bytes. | |
| Request Body - size: 32 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 643 bytes. | |
| URL | https://vulnweb.rootbrain.com/SQL/sql3.php |
| Method | POST |
| Parameter | |
| Attack | |
| Evidence | <form action="" method="post" > |
| Request Header - size: 853 bytes. | |
| Request Body - size: 29 bytes. | |
| Response Header - size: 212 bytes. | |
| Response Body - size: 745 bytes. | |
| Instances | 33 |
| Solution |
Phase: Architecture and Design
Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
For example, use anti-CSRF packages such as the OWASP CSRFGuard.
Phase: Implementation
Ensure that your application is free of cross-site scripting issues, because most CSRF defenses can be bypassed using attacker-controlled script.
Phase: Architecture and Design
Generate a unique nonce for each form, place the nonce into the form, and verify the nonce upon receipt of the form. Be sure that the nonce is not predictable (CWE-330).
Note that this can be bypassed using XSS.
Identify especially dangerous operations. When the user performs a dangerous operation, send a separate confirmation request to ensure that the user intended to perform that operation.
Note that this can be bypassed using XSS.
Use the ESAPI Session Management control.
This control includes a component for CSRF.
Do not use the GET method for any request that triggers a state change.
Phase: Implementation
Check the HTTP Referer header to see if the request originated from an expected page. This could break legitimate functionality, because users or proxies may have disabled sending the Referer for privacy reasons.
|
| Reference |
http://projects.webappsec.org/Cross-Site-Request-Forgery
http://cwe.mitre.org/data/definitions/352.html |
| Tags |
OWASP_2021_A01
WSTG-v42-SESS-05 OWASP_2017_A05 |
| CWE Id | 352 |
| WASC Id | 9 |
| Plugin Id | 10202 |
|
Medium |
Application Error Disclosure |
|---|---|
| Description |
This page contains an error/warning message that may disclose sensitive information like the location of the file that produced the unhandled exception. This information can be used to launch further attacks against the web application. The alert could be a false positive if the error message is found inside a documentation page.
|
| URL | https://vulnweb.rootbrain.com/Resources/ |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 254 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=D;O=A |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 313 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=D;O=D |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 321 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=M;O=A |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 313 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=M;O=D |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 321 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=N;O=A |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 321 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=N;O=D |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 313 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=S;O=A |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 313 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| URL | https://vulnweb.rootbrain.com/Resources/?C=S;O=D |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | Parent Directory |
| Request Header - size: 321 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 156 bytes. | |
| Response Body - size: 1,696 bytes. | |
| Instances | 9 |
| Solution |
Review the source code of this page. Implement custom error pages. Consider implementing a mechanism to provide a unique error reference/identifier to the client (browser) while logging the details on the server side and not exposing them to the user.
|
| Reference | |
| Tags |
WSTG-v42-ERRH-02
WSTG-v42-ERRH-01 OWASP_2021_A05 OWASP_2017_A06 |
| CWE Id | 200 |
| WASC Id | 13 |
| Plugin Id | 90022 |
|
Medium |
Content Security Policy (CSP) Header Not Set |
|---|---|
| Description |
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement or distribution of malware. CSP provides a set of standard HTTP headers that allow website owners to declare approved sources of content that browsers should be allowed to load on that page — covered types are JavaScript, CSS, HTML frames, fonts, images and embeddable objects such as Java applets, ActiveX, audio and video files.
|
| URL | http://vulnweb.rootbrain.com/vulnweb/CommandExecution/ |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | |
| Request Header - size: 325 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 145 bytes. | |
| Response Body - size: 196 bytes. | |
| URL | http://vulnweb.rootbrain.com/vulnweb/Resources/ |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | |
| Request Header - size: 311 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 145 bytes. | |
| Response Body - size: 196 bytes. | |
| URL | https://optimizationguide-pa.googleapis.com/downloads?name=1673999601&target=OPTIMIZATION_TARGET_PAGE_VISIBILITY |
| Method | GET |
| Parameter | |
| Attack | |
| Evidence | |
| Request Header - size: 472 bytes. | |
| Request Body - size: 0 bytes. | |
| Response Header - size: 475 bytes. | |
| Response Body - size: 883,094 bytes. | |